Chris Colefax and I were discussing about improvements of the compressed
mesh macros so that they could be easier to maintain and use. He noted that
the parsing of #macros is so slow (specially when #included from an external
file) that he is not using them in many places where speed is needed. This
of course causes some serious problems in modularity and usability.
  Why #macros are so slow specially when #included? Can this be improved?

  Here is a copy of Chris' original response (with his permission):

From cco### [at] geocitiescom Sun Jan  9 18:24:47 2000
Date: Sat, 8 Jan 2000 11:19:22 +1000
From: Chris Colefax <cco### [at] geocitiescom>
To: Nieminen Juha <war### [at] cstutfi>
Subject: Re: A comment about the pcm macro

Warp,

I guess it must seem rather ridiculous to repeat as much macro code as I
have, and while I was writing the latest updates for MeshComp 2.1 I have to
admit I considered simplifying the mesh creation macros in just the way you
describe.

However, there is actually a reason I wrote the macros as I did -
performance.  In every situation I've tested (various OS's, file caching
on/off) macros parse considerably slower when called in a loop from an
include file as opposed to defining the macro in the same POV file as it is
called from, or (fastest of all) placing the code to be executed directly
within the loop.

A simple example:

   #macro M () #declare C = C + 1; #end
   #declare C = 0; #while (C < 10000) M () #end

On my machine, saved and run from a single file this code takes about twice
as long as incrementing the counter directly without a macro.   Placing the
macro into an included file runs about 7-8 times slower again (ie. 14-16
times as slow as not using the macro!).

Personally I felt it was worth sacrificing simplicity for speed, particuarly
considering how the mesh creation macros might be used.  There may well be a
case for allowing both options, so that users who want to quickly write a
mesh creation macro for, say, a still scene can do so without worrying about
the full coding.  And maybe raising the above parsing performance issues in
povray.programming could lead to a patch that eliminates speed concerns
altogether (hint, hint!)?

Yours,

Chris.

---------------------
>   I examined yur pcm.mcr and noticed one thing that might be done better.
>   I don't want to preach you about programming guidelines or modularity or
> anything like that, but I noticed that the code to read the pcm data is
> copied several times in the file (each mesh creation macro has the same
> code copied).
>   This, as you probably know, is not a good idea. If you have to make a
> change to the code, you have to do it many times with the risk that you
> don't make the change properly in every place. It also requires lots of
> work to maintain this (it can be specially seen with the new PCM3
support).
>   But the most important thing is that it makes it difficult for the user
> to make his own mesh creation macros. The user must copy the same
(lengthy)
> code each time he wants the make a mesh creation macro.
>   I think that there should be a set of macros which can be used to more
> easyly read the mesh data. The logics of the mesh decompression should be
> completely hidden inside these macros; the only thing that the macros
should
> do is the "gimme the next triangle, please"-functionality.
>   Doing it this way will save you and the user lots of trouble and work.
> It will make it easier to you to modify the code and add new functionality
> and it will also make it a lot easier for the user to make his own macros.
> The user wouldn't even have to worry about what type of input file is he
> reading (PCM1 or PCM3) because the reading macros would hide that
unnecesary
> information inside them.
>   In an optimal case, if in the future we add some new type of triangle
> mesh format (e.g. PCM4), the only modifications needed could be done in
> the reading macros and the mesh creation macros could be left untouched.
> It would also save lots of work since the modifications had to be made
only
> in one place (instead of having to modify lots of mesh creation macros).
> Also all the user-made mesh creation macros would work as-is, without
> modification, with the new format.




-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message